feat!: show input from a new line#4727
feat!: show input from a new line#4727knocte wants to merge 6 commits intoconventional-changelog:masterfrom
Conversation
Review Summary by QodoAdd multi-line input display with legacy output flag support
WalkthroughsDescription• Change default input output format to multi-line with --- input --- banner • Add --legacy-output flag to restore single-line input: ... format • Add comprehensive test cases for both new and legacy output formats • Update documentation examples to reflect new default output format Diagramflowchart LR
A["CLI Input"] --> B["Format Module"]
B --> C{"legacyOutput Flag?"}
C -->|true| D["Single-line: input: ..."]
C -->|false| E["Multi-line: --- input ---"]
D --> F["Output Display"]
E --> F
File Changes1. @commitlint/cli/src/cli.ts
|
Code Review by Qodo
1. URL-in-body regression test missing
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
There was a problem hiding this comment.
Pull request overview
Updates commitlint’s text formatter to display the commit message input starting on a new line (with an --- input --- banner) to make error output clearer and easier to copy/paste, while adding an opt-in legacy mode for the previous single-line input: display.
Changes:
- Change the default formatted “input” output to a banner + newline style in
@commitlint/format. - Add
legacyOutput/--legacy-outputto preserve the previous single-lineinput: ...output format. - Update several docs/examples and extend formatter test coverage for the new/legacy outputs.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| docs/guides/local-setup.md | Updates example output to match the new multi-line input banner format. |
| @commitlint/types/src/format.ts | Extends FormatOptions with legacyOutput?: boolean. |
| @commitlint/format/src/format.ts | Implements the new input banner output and legacy toggle. |
| @commitlint/format/src/format.test.ts | Adds tests for new banner output and legacy output. |
| @commitlint/config-rush-scopes/readme.md | Updates shown CLI output to use the new input banner. |
| @commitlint/config-pnpm-scopes/readme.md | Updates shown CLI output to use the new input banner. |
| @commitlint/config-nx-scopes/readme.md | Updates shown CLI output to use the new input banner. |
| @commitlint/config-lerna-scopes/readme.md | Updates shown CLI output to use the new input banner. |
| @commitlint/cli/src/types.ts | Adds legacy-output to CLI flags typing. |
| @commitlint/cli/src/cli.ts | Adds --legacy-output yargs option and passes through to formatter options. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ❯ echo "build(api): change something in api's build" | commitlint | ||
| ⧗ input: build(api): change something in api's build | ||
| ⧗ --- input --- | ||
| build(api): change something in api's build | ||
| ✔ found 0 problems, 0 warnings |
There was a problem hiding this comment.
These examples show output for a successful lint ("found 0 problems") but the CLI doesn't print anything on success unless --verbose is used (see docs/guides/local-setup.md). To keep the README accurate, either add --verbose to the example commands or remove the success output blocks.
| ❯ echo "build(api): change something in api's build" | commitlint | ||
| ⧗ input: build(api): change something in api's build | ||
| ⧗ --- input --- | ||
| build(api): change something in api's build | ||
| ✔ found 0 problems, 0 warnings |
There was a problem hiding this comment.
These examples include output for passing commits without showing --verbose, but commitlint suppresses output on success by default. Please update the commands to include --verbose (or adjust the shown output) so the README matches actual CLI behavior.
| ❯ echo "build(api): change something in api's build" | commitlint | ||
| ⧗ input: build(api): change something in api's build | ||
| ⧗ --- input --- | ||
| build(api): change something in api's build | ||
| ✔ found 0 problems, 0 warnings | ||
|
|
There was a problem hiding this comment.
The success-case examples here show output even though commitlint prints nothing for valid messages unless --verbose is provided. Consider adding --verbose to the example commands (or removing the success output) to avoid confusing users who copy/paste.
| ❯ echo "build(api): change something in api's build" | commitlint | ||
| ⧗ input: build(api): change something in api's build | ||
| ⧗ --- input --- | ||
| build(api): change something in api's build | ||
| ✔ found 0 problems, 0 warnings | ||
|
|
There was a problem hiding this comment.
Like the other config READMEs, this shows output for a passing commit without --verbose, but commitlint is silent on success by default. Please align the example commands/output (e.g., add --verbose) so the documentation reflects real behavior.
knocte
force-pushed
the
finishPr4102
branch
4 times, most recently
from
52731bb to
7f02bb0
Compare
|
@escapedcat I think this is ready to merge (when we're ready to do the big version bump with breaking changes, not now). The only feedback I didn't address from Copilot is:
|
And by this I mean that they'll likely find about this change in the CHANGELOG/ReleaseNotes; they're not going to read the documentation ;) |
|
I guess we don't lose anything by adding it to the docs and removing it later again. I don't think it's polluting them. Another small feedback from Claude I think it's worth doing:
So maybe write a commit body and state this plan? |
|
@knocte thanks for picking this up! 👍 |
Alright, added a commit to address this. |
This will be less confusing to read, and also easier to test and copy/paste.
Previous commit adtoped a new output format by default, so we need to reflect it in the docs like it's done here.
As instructed by GitHub Copilot, we add a new testcase.
To restore old single-line input output.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.
Comments suppressed due to low confidence (1)
@commitlint/cli/src/cli.test.ts:651
- The new
--legacy-outputflag is added to the help snapshot, but there isn't a behavioral test asserting that passing--legacy-outputactually produces the legacyinput: ...line (and that default output uses the banner). Adding an integration-style CLI test for this flag would prevent regressions in the flag→formatter option wiring.
test("should print help", async () => {
const cwd = await gitBootstrap("fixtures/default");
const result = cli(["--help"], { cwd })();
const output = await result;
const version = require("../package.json").version;
const stdout = output.stdout.trim().replace(`@${version}`, "@dev");
expect(stdout).toMatchInlineSnapshot(`
"@commitlint/cli@dev - Lint your commit messages
[input] reads from stdin if --edit, --env, --from and --to are omitted
Options:
-c, --color toggle colored output [boolean] [default: true]
-g, --config path to the config file; result code 9 if config is missing [string]
--print-config print resolved config [string] [choices: "", "text", "json"]
-d, --cwd directory to execute in [string] [default: (Working Directory)]
-e, --edit read last commit message from the specified file or fallbacks to ./.git/COMMIT_EDITMSG [string]
-E, --env check message in the file at path given by environment variable value [string]
-x, --extends array of shareable configurations to extend [array]
-H, --help-url help url in error message [string]
-f, --from lower end of the commit range to lint; applies if edit=false [string]
--from-last-tag uses the last tag as the lower end of the commit range to lint; applies if edit=false and from is not set [boolean]
--git-log-args additional git log arguments as space separated string, example '--first-parent --cherry-pick' [string]
-l, --last just analyze the last commit; applies if edit=false [boolean]
-o, --format output format of the results [string]
-p, --parser-preset configuration preset to use for conventional-commits-parser [string]
-q, --quiet toggle console output [boolean] [default: false]
-t, --to upper end of the commit range to lint; applies if edit=false [string]
-V, --verbose enable verbose output for reports without problems [boolean]
--legacy-output use the legacy input output format (single-line 'input: ...') [boolean]
-s, --strict enable strict mode; result code 2 for warnings, 3 for errors [boolean]
--options path to a JSON file or Common.js module containing CLI options
-v, --version display version information [boolean]
-h, --help Show help [boolean]"
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # husky > commit-msg | ||
| ``` | ||
|
|
||
| Since [v22.0.0](https://github.com/conventional-changelog/commitlint/releases/tag/v22.0.0) `commitlint` will output the commit message after a new line (EOL) instead of after a colon.\ |
| Since [v22.0.0](https://github.com/conventional-changelog/commitlint/releases/tag/v22.0.0) `commitlint` will output the commit message after a new line (EOL) instead of after a colon.\ | ||
| (You can use the `--legacy-output` flag to get the previous output format used in older versions) |
Supersedes #4102
This will be less confusing to read, and also easier to test and copy/paste (for example for #4101).
This error log is confusing for people not familiar with
commitlint.This one should be more clear.
Or maybe even this one.
Motivation and Context
Error output should not mess up original commit message, because it is hard to understand what is wrong.
Usage examples
How Has This Been Tested?
Types of changes
Checklist: